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DETAILED ACTION 
Claim Rejections - 35 USC § 102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

Claims 1-21 are rejected under 35 U.S.C. 102 (b) as being anticipated by Mikhailov et al 
hereinafter Mikhailov (US 6,990534 B2). 

Regarding claim 1 

Mikhailov discloses a method of enabling use of an application server application by a 
wireless communication device comprising, at a transaction server: on receipt of a given 
message from said wireless communication device for said application on said 
application server, pushing said given message, and each message queued on a queue 
for said application, toward a destination for said application of said application server. 

(Col. 61 FIG. 34B is a block diagram illustrating the invented application-specific device 
presence monitoring. The registration/deregistration request originates on the device as a result 
of routine 17000. It is submitted from the PAT 22 through Mobile Network(s) 25009, 25010 to 
Gateway(s) 25001, 25002, which will deliver the request to the Presence Monitor 1019 in the 
PES 27. The Presence Monitor 1019 checks the records according to algorithm 23000, and may 
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communicate with Routing Tables 1032 to obtain device status before the request arrived. If the 
device status is changed, it will issue device presence update message to the Push Manager 1012, 
which through the Push Interface 1014 will publish the message to some Messaging System 
25008, 25003, to a specific Topic or Queue 25012 the Application Server 25005, 25004 is 
subscribed to, through Subscription(s) 25004. Then Application Server 25005, 25004 receives 
the device network presence update message and may execute the application-specific logic. It is 
understood that the described process is an optional extension, which may be ignored by the 
applications not sensitive to device network presence.) 



Regarding claim 2 

Referring to claim 2 Mi[<liailov discloses all the limitations of claim 2 which is described 
above. Mikhailov also discloses queuing said given message on said queue prior to 
pushing said given message, and wherein said pushing comprises, for each message 
on said queue, dequeuing said each message from said queue and pushing said each 
message. (Col. 61 Fig. 61 FIG. 34A is a block diagram illustrating the invented server-initiated 
content delivery process (see also FIG. 35A). The delivery request originates at the application 
server 25005, 25007, in response to application algorithms, that can be defined by those skilled 
in art at application design time. The request then follows to Messaging Systems 25003, 25008 
to the messaging queue or topic that the application and PES 27 negotiated for content delivery 
requests. In this architecture the AppUcation Server 25005, 25007 is the publisher of the 
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messages to the messaging topics or queues 25012 and the PES 27 is the subscriber for the 
messages through message subscription(s) 25004. When the message arrives to the PES 27 it is 
received by Push Interface 1014, which provides bridging and decoding functions between 
Messaging System 25003, 25008 and PES 27 components. Once the message is processed the 
information follows to the Content Manager 1021, which fetches content delivery request data 
from the Application Servers 25005, 25007 or any other content provider using HTTP requests 
through Web Server 24 or other applicable means. Upon it receiving the data PES 27, 
preprocesses and validates it, and saves the content to the Queue 46, which stores the content in 
Queue storage 1020. In the next step the Content Manager 1021 communicates to the router 
1017, which reads information from Routing tables 47, to decide if the device is available and 
can process server-initiated content delivery. Once the device is available, the content is sent to 
the PAT 22 through one or more gateways 25001, 25002 and Mobile Networks 25009, 25010. At 
this point the device receives the content and follows the algorithms described above to present 
the content to the user. During content delivery queuing and other related delivery processing 
Push Manager 1012 generates messages with delivery status notifications on each status change 
and publishes them through the Push Interface 1014 to messaging Queues or Topics 25012 in 
Messaging System 25003, 25008. Application Server 25005, 25007 can subscribe to the queues 
and topics through Subscriptions 25004 in order to obtain delivery status notifications if they are 
required by the application algorithms. Currently the PES 27 generates the messages for the 
following delivery events: The content is placed in the queue; The content is replaced in the 
queue (older content was suppressed to ensure delivery of the most fresh content only); The 
content delivery failed (with attempt nimiber and error code), and delivery attempts will continue 
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until queue for the frame expires; The content is delivered to the target device; The content 
expired (queue for the frame may be reset upon expiration of appUcation-configured timeout) 

Regarding claim 3 

Referring to claim 3 Mikhailov discloses all the limitations of claim 3 which is described 
above Mikhailov also discloses prior to said dequeuing and pushing, acquiring a lock for 
said destination on said application server, said lock preventing other use of said 

destination. (Col. 23 lines 61-67 and Col. 25 lines 1-3 If field worker accepts the work order, the 
"YES" branch is followed to routine 2046, in which the application updates the work order 
information, and locks it so that multiple field workers are not assigned to perform the same 
work. Then the application enters idle state until the application receives work order completion 
notification from the field worker; it follows to routine 2047, in which the application updates 
work order information according to the response from the field worker, and follows to routine 
2048. In routine 2048 the system may send status reports to the field worker. Routine 2048 is 
followed by the "END" step, which concludes routine 2020.) 



Regarding claim 4 
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Referring to claim 4 Mil<liailov discloses The method of claim 2 further comprising, after 
said dequeuing said each message from said queue and pushing said each message, 
releasing said lock for said destination on said application server. (Col.23 lines 61-67 and 
Col. 25 lines 1-3 If field worker accepts the work order, the "YES" branch is followed to routine 

2046, in which the application updates the work order information, and locks it so that multiple 
field workers are not assigned to perform the same work. Then the application enters idle state 
until the application receives work order completion notification from the field worker; it follows 
to routine 2047, in which the application updates work order information according to the 
response from the field worker, and follows to routine 2048. In routine 2048 the system may 
send status reports to the field worker. Routine 2048 is followed by the "END" step, which 
concludes routine 2020.) 

Regarding claim 5 

Referring to claim 5 Mikhailov discloses all the limitations of claim 5 which is described 
above. Mikhailov also discloses wherein messages on said queue are queued on a first 
in first out (FIFO) basis and wherein a trailing message in said queue is not pushed until 
a message in said queue immediately preceding said trailing message is considered to 
have successfully reached said destination (Col. 61 Fig. 61 FIG. 34A is a block diagram 
illusfrating the invented server-initiated content delivery process (see also FIG. 35A). The 
delivery request originates at the application server 25005, 25007, in response to application 
algorithms, that can be defined by those skilled in art at application design time. The request then 



Application/Control Number: 10/537,430 Page 7 

Art Unit: 2154 

follows to Messaging Systems 25003, 25008 to the messaging queue or topic that the application 
and PES 27 negotiated for content delivery requests. In this architecture the Application Server 
25005, 25007 is the publisher of the messages to the messaging topics or queues 25012 and the 
PES 27 is the subscriber for the messages through message subscription(s) 25004. When the 
message arrives to the PES 27 it is received by Push Interface 1014, which provides bridging and 
decoding functions between Messaging System 25003, 25008 and PES 27 components. Once the 
message is processed the information follows to the Content Manager 1021, which fetches 
content delivery request data from the Application Servers 25005, 25007 or any other content 
provider using HTTP requests through Web Server 24 or other applicable means. Upon it 
receiving the data PES 27, preprocesses and validates it, and saves the content to the Queue 46, 
which stores the content in Queue storage 1020. In the next step the Content Manager 1021 
communicates to the router 1017, which reads information from Routing tables 47, to decide if 
the device is available and can process server-initiated content delivery. Once the device is 
available, the content is sent to the PAT 22 through one or more gateways 25001, 25002 and 
Mobile Networks 25009, 25010. At this point the device receives the content and follows the 
algorithms described above to present the content to the user. During content delivery queuing 
and other related delivery processing Push Manager 1012 generates messages with delivery 
status notifications on each status change and publishes them through the Push Interface 1014 to 
messaging Queues or Topics 25012 in Messaging System 25003, 25008. Application Server 
25005, 25007 can subscribe to the queues and topics through Subscriptions 25004 in order to 
obtain delivery status notifications if they are required by the application algorithms. Currently 
the PES 27 generates the messages for the following delivery events: The content is placed in the 
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queue; The content is replaced in the queue (older content was suppressed to ensure delivery of 
the most fresh content only); The content delivery failed (with attempt number and error code), 
and delivery attempts will continue until queue for the frame expires; The content is delivered to 
the target device; The content expired (queue for the frame may be reset upon expiration of 
application-configured timeout) 

Regarding claim 6 

Referring to claim 6 Mikhailov discloses if a particular message pushed toward said 
destination does not successfully reach said destination, ceasing said dequeuing and 
pushing and re-queuing said particular message on said queue. (Col.62 Fig.35B lines 39- 
55 FIG. 35B is a logic flow diagram illustrating content loading routine 26004 of the server- 
initiated content delivery process 26000. This routine is typically implemented by the content 
manager 1021 in the PES 27. Routine 26004 starts with routine 26030, in which the content 
manager 1021 receives request to download certain content for the server-initiated content 
delivery request. Routine 26030 follows to routine 26031 in which the content manager 1021 
loads the content from the URL read from the content delivery request and follows to the step 
25033, in which it checks whether loading was successful. If loading was not successful, the 
"NO" branch is followed to routine 26043, in which the PES 27 sends the delivery failed 
message to the application server, which initiated content delivery request, through Messaging 
System 25008, 25003. If loading was successftil, the "YES" branch is followed to the step 
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25035, in which the server checks if the content is of supported type. Here supported type is the 
type, which can be transformed by the gateway 23 to the type understood by the PAT 22.) 

Regarding claim 7 

Referring to claim 7 Mikhailov discloses on dequeuing said each message and prior to 
pushing said each message (Col. 61 Fig. 61 FIG. 34A is a block diagram illustrating the 
invented server-initiated content delivery process (see also FIG. 35A). The delivery request 
originates at the application server 25005, 25007, in response to appHcation algorithms, that can 
be defined by those skilled in art at application design time. The request then follows to 
Messaging Systems 25003, 25008 to the messaging queue or topic that the application and PES 
27 negotiated for content delivery requests. In this architecture the Application Server 25005, 
25007 is the publisher of the messages to the messaging topics or queues 25012 and the PES 27 
is the subscriber for the messages through message subscription(s) 25004. When the message 
arrives to the PES 27 it is received by Push Interface 1014, which provides bridging and 
decoding functions between Messaging System 25003, 25008 and PES 27 components. Once the 
message is processed the information follows to the Content Manager 1021, which fetches 
content delivery request data from the Application Servers 25005, 25007 or any other content 
provider using HTTP requests through Web Server 24 or other applicable means. Upon it 
receiving the data PES 27, preprocesses and validates it, and saves the content to the Queue 46, 
which stores the content in Queue storage 1020. In the next step the Content Manager 1021 
communicates to the router 1017, which reads information from Routing tables 47, to decide if 
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the device is available and can process server-initiated content delivery. Once the device is 
available, the content is sent to the PAT 22 through one or more gateways 25001, 25002 and 
Mobile Networks 25009, 25010. At this point the device receives the content and follows the 
algorithms described above to present the content to the user. During content delivery queuing 
and other related delivery processing Push Manager 1012 generates messages with delivery 
status notifications on each status change and publishes them through the Push Interface 1014 to 
messaging Queues or Topics 25012 in Messaging System 25003, 25008. Apphcation Server 
25005, 25007 can subscribe to the queues and topics through Subscriptions 25004 in order to 
obtain delivery status notifications if they are required by the application algorithms. Currently 
the PES 27 generates the messages for the following delivery events: The content is placed in the 
queue; The content is replaced in the queue (older content was suppressed to ensure delivery of 
the most fresh content only); The content delivery failed (with attempt number and error code), 
and delivery attempts will continue until queue for the frame expires; The content is delivered to 
the target device; The content expired (queue for the frame may be reset upon expiration of 
application-configured timeout), logging said event and wlierein said re-queuing said 
particular message comprises utilizing said log to identify messages to re-queue. (Col.22 
lines 45-50 Logging and Inventory Management Engine (LIME) 1045, is a logging component, 
which collects and logs PAT-generated errors and warnings for inspection by administrators and 
application developers; Distributed Log 1046, is a non- volatile storage used to store information 
on errors, warnings, messages, and inventory data. It may be implemented as databases, files, 
etc.) 
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Referring to claim 8 Mikhailov discloses all the limitations of claim 8 which is described 
above. Mikhailov also discloses timing a retry interval and, expiry of said retry interval, 
for each message on said queue: dequeuing said each message from said queue and 
pushing said each message from said queue and pushing said each message toward 
said destination for said application of said server. (Col. 61 Fig. 61 FIG. 34A is a block 
diagram illustrating the invented server-initiated content delivery process (see also FIG. 35A). 
The delivery request originates at the application server 25005, 25007, in response to application 
algorithms, that can be defined by those skilled in art at application design time. The request then 
follows to Messaging Systems 25003, 25008 to the messaging queue or topic that the apphcation 
and PES 27 negotiated for content delivery requests. In this architecture the Application Server 
25005, 25007 is the publisher of the messages to the messaging topics or queues 25012 and the 
PES 27 is the subscriber for the messages through message subscription(s) 25004. When the 
message arrives to the PES 27 it is received by Push Interface 1014, which provides bridging and 
decoding functions between Messaging System 25003, 25008 and PES 27 components. Once the 
message is processed the information follows to the Content Manager 1021, which fetches 
content delivery request data from the Application Servers 25005, 25007 or any other content 
provider using HTTP requests through Web Server 24 or other applicable means. Upon it 
receiving the data PES 27, preprocesses and validates it, and saves the content to the Queue 46, 
which stores the content in Queue storage 1020. In the next step the Content Manager 1021 
communicates to the router 1017, which reads information from Routing tables 47, to decide if 
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the device is available and can process server-initiated content delivery. Once the device is 
available, the content is sent to the PAT 22 through one or more gateways 25001, 25002 and 
Mobile Networks 25009, 25010. At this point the device receives the content and follows the 
algorithms described above to present the content to the user. During content delivery queuing 
and other related delivery processing Push Manager 1012 generates messages with delivery 
status notifications on each status change and publishes them through the Push Interface 1014 to 
messaging Queues or Topics 25012 in Messaging System 25003, 25008. Apphcation Server 
25005, 25007 can subscribe to the queues and topics through Subscriptions 25004 in order to 
obtain delivery status notifications if they are required by the application algorithms. Currently 
the PES 27 generates the messages for the following delivery events: The content is placed in the 
queue; The content is replaced in the queue (older content was suppressed to ensure delivery of 
the most fresh content only); The content delivery failed (with attempt number and error code), 
and delivery attempts will continue until queue for the frame expires; The content is delivered to 
the target device; The content expired (queue for the frame may be reset upon expiration of 
application-configured timeout), 

Regarding claim 9 

Referring to claim 9 Mil<liailov discloses all the limitations of claim 9 which is described 
above. Mikhailov also discloses wherein said destination is a Component Object Model 
interface, a Distributed Component Object Model interface. Simple Object Access 
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Protocol interface, a .NET interface, or a .NETRemoting interface. (Col.21 lines 32-53 The 
server system 1099 may include the following components: Proactivity Enablement Server 
(PES) 27, is a server software system, which facilitates server-initiated content delivery to 
mobile devices and is specially tailored for development and deployment of proactive wireless 
applications; Queue Storage 1020, is a supplement to PES, which stores content delivery request 
data for PES. It may be implemented using databases, files, etc.; Web Server 24, is a standard 
HTTP server or any other suitable application system, which is serving content requests and/or 
delivers information in the fixed network (Internet, Intranet, etc); Messaging System 1007, is a 
supplementary component, which function is to enable routing and delivery of digital messages 
in heterogeneous computing environment using well-defined messaging protocols. Examples of 
such messaging products include but not limited to Java Messaging Server (JMS) 
implementations, Microsoft MSMQ, Web Services SOAP protocol, and so forth; Application 
Server 25, is a system, which handles application logic and related code for proactive data 
applications 49 and submits content delivery requests to the Messaging System 1007 (LI); 
Database 26, is a component, which fimction is to store and manage application and other related 
data; other unlisted components, may be required to enable or extend functionality and/or 
performance of the system; PES 27 consists of the following modules). 

Regarding claim 10 



Referring to claim 10 Mikhailov discloses all the limitations of claim 10 which is 
described above. Mikhailov also discloses wherein said acquiring a lock comprises 
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sending a lock request to a remote lock server. (Col.23 lines 61-67 and Col. 25 lines 1-3 If 
field worker accepts the work order, the "YES" branch is followed to routine 2046, in which the 
application updates the work order information, and locks it so that multiple field workers are not 
assigned to perform the same work. Then the application enters idle state until the application 
receives work order completion notification from the field worker; it follows to routine 2047, in 
which the application updates work order information according to the response from the field 
worker, and follows to routine 2048. In routine 2048 the system may send status reports to the 
field worker. Routine 2048 is followed by the "END" step, which concludes routine 2020.) 



Regarding claim 11 

Referring to claim 1 1 Mikhailov discloses all the limitations of claim 1 1 which is 
described above. Mikhailov also discloses wherein said each message is an extensible 
markup language package. (Col.l 1 lines 44 - 47 The document formats that may be 
supported by PAT are not restricted to a particular format and may include any data presentation 
format such as HTML, xHTML, XML, WML, SVG, etc.) 

Regarding claim 12 

Referring to claim 12 Mikhailov discloses all the limitations of claim 12 which is 
described above. Mikhailov also discloses receiving a polling request from said 
application server, said polling request establishing a transaction; and dequeing said 
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each message from said queue and sending said eacli message toward said 
destination for said application of said application server in the context of said 
transaction. (Col.23 lines 61-67 and Col. 25 lines 1-3 If field worker accepts the work order, the 
"YES" branch is followed to routine 2046, in which the application updates the work order 

information, and locks it so that multiple field workers are not assigned to perform the same 
work. Then the application enters idle state until the application receives work order completion 
notification from the field worker; it follows to routine 2047, in which the application updates 
work order information according to the response from the field worker, and follows to routine 
2048. In routine 2048 the system may send status reports to the field worker. Routine 2048 is 
followed by the "END" step, which concludes routine 2020.) 



Regarding claim 13 

Referring to claim 13 Mikhailov discloses all the limitations of claim 13 which is 
described above. Mikhailov also discloses receiving from said application server a 
message fro said mobile communication device; and forwarding said application server 
message to said wireless communication device. (Col. 61 FIG. 34B is a block diagram 
illustrating the invented application-specific device presence monitoring. The 
regisfration/deregisfration request originates on the device as a result of routine 17000. It is 
submitted from the PAT 22 through Mobile Network(s) 25009, 25010 to Gateway(s) 25001, 
25002, which will deliver the request to the Presence Monitor 1019 in the PES 27. The Presence 
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Monitor 1019 checks the records according to algorithm 23000, and may communicate with 
Routing Tables 1032 to obtain device status before the request arrived. If the device status is 
changed, it will issue device presence update message to the Push Manager 1012, which through 
the Push Interface 1014 will publish the message to some Messaging System 25008, 25003, to a 
specific Topic or Queue 25012 the AppUcation Server 25005, 25004 is subscribed to, through 
Subscription(s) 25004. Then Application Server 25005, 25004 receives the device network 
presence update message and may execute the application-specific logic. It is understood that the 
described process is an optional extension, which may be ignored by the applications not 
sensitive to device network presence.) 



Regarding claim 14 

Referring to claim 14 Mikhailov discloses all the limitations of claim 14 which is 
described above. Mikhailov also discloses wherein said pushing said each message 
toward said destination for said application of said application server comprising 
sending said message to a universal resource locator (URL). (Col. 21 lines 32-67 and 
Col. 22 lines 1-32 The server system 1099 may include the following components: Proactivity 
Enablement Server (PES) 27, is a server software system, which facilitates server-initiated 
content delivery to mobile devices and is specially tailored for development and deployment of 
proactive wireless applications; Queue Storage 1020, is a supplement to PES, which stores 
content delivery request data for PES. It may be implemented using databases, files, etc.; Web 
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Server 24, is a standard HTTP server or any other suitable application system, which is serving 
content requests and/or delivers information in the fixed network (Intemet, Intranet, etc); 
Messaging System 1007, is a supplementary component, which fiinction is to enable routing and 
delivery of digital messages in heterogeneous computing environment using well-defined 
messaging protocols. Examples of such messaging products include but not limited to Java 
Messaging Server (JMS) implementations, Microsoft MSMQ, Web Services SOAP protocol, and 
so forth; Application Server 25, is a system, which handles application logic and related code for 
proactive data applications 49 and submits content delivery requests to the Messaging System 
1007 (LI); Database 26, is a component, which function is to store and manage application and 
other related data; other unlisted components, may be required to enable or extend functionality 
and/or performance of the system; PES 27 consists of the following modules: Push Interface 
1014, is a communication interface to Messaging System 1007, which receives content delivery 
requests from Application Server 25 and delivers them to Content Manager 1021 . It also obtains 
device presence notifications and content delivery status updates (L2) from Push Manager 1012 
and publishes them to Messaging System 1007, which delivers the updates to the Application 
Server 25 (L3). Content Manager 1021, is a special communication component that interfaces 
with the Web Server 24, which upon receiving content delivery request containing content 
location information, such as URL, fetches the data from the Web Server 24, validates, parses, 
and supplies the content to Push Manager 1012 and Queue 46; Push Manager 1012, is the main 
engine for managing content delivery requests and sending out events on device presence to the 
Application Server 25. Through Router 1017, it supphes content to the device as defined in WAP 
Push, Push Access Protocol (PAP), or other applicable specifications.) 
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Regarding claim 15 

Mikhailov discloses a metliod, at a transaction server, of enabling use of an application 
on an application server at a mobile communication device, comprising: receiving from 
said mobile a mobile data containing package; pushing said mobile data containing 
package to said application server; receiving from said application server a server data 
containing package; forwarding said server data containing package to said mobile. 
(Col. 61 FIG. 34B is a block diagram illustrating the invented application-specific device 
presence monitoring. The registration/deregistration request originates on the device as a result 
of routine 17000. It is submitted fi-om the PAT 22 through Mobile Network(s) 25009, 25010 to 
Gateway(s) 25001, 25002, which will deliver the request to the Presence Monitor 1019 in the 
PES 27. The Presence Monitor 1019 checks the records according to algorithm 23000, and may 
communicate with Routing Tables 1032 to obtain device status before the request arrived. If the 
device status is changed, it will issue device presence update message to the Push Manager 1012, 
which through the Push Interface 1014 will publish the message to some Messaging System 
25008, 25003, to a specific Topic or Queue 25012 the Application Server 25005, 25004 is 
subscribed to, through Subscription(s) 25004. Then Application Server 25005, 25004 receives 
the device network presence update message and may execute the application-specific logic. It is 
understood that the described process is an optional extension, which may be ignored by the 
applications not sensitive to device network presence.) 
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Mikhailov discloses a transaction server enabling use of at least one application server 
application by a wireless communication device, comprising: a memory storing at least 
one queue, with one queue being provided for each of said at least one application on 
said application server; a processor for on receipt of a given message from said 
wireless communication device, comprising : a memory storing at least one queue, with 
one queue being provided for each of said at least one application on said application 
server; a processor for, on receipt of a given message from said wireless 
communication device for a given application on said application server: pushing said 
given message, and each message queued on a queue for said application, toward a 
destination for said application server. (Col. 61 Fig. 61 FIG. 34A is a block diagram 
illustrating the invented server-initiated content delivery process (see also FIG. 35A). The 
delivery request originates at the application server 25005, 25007, in response to application 
algorithms that can be defined by those skilled in art at application design time. The request then 
follows to Messaging Systems 25003, 25008 to the messaging queue or topic that the application 
and PES 27 negotiated for content delivery requests. In this architecture the Application Server 
25005, 25007 is the publisher of the messages to the messaging topics or queues 25012 and the 
PES 27 is the subscriber for the messages through message subscription(s) 25004. When the 
message arrives to the PES 27 it is received by Push Interface 1014, which provides bridging and 
decoding functions between Messaging System 25003, 25008 and PES 27 components. Once the 
message is processed the information follows to the Content Manager 1021, which fetches 
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content delivery request data from the Application Servers 25005, 25007 or any other content 
provider using HTTP requests through Web Server 24 or other applicable means. Upon it 
receiving the data PES 27, preprocesses and validates it, and saves the content to the Queue 46, 
which stores the content in Queue storage 1020. In the next step the Content Manager 1021 
communicates to the router 1017, which reads information from Routing tables 47, to decide if 
the device is available and can process server-initiated content delivery. Once the device is 
available, the content is sent to the PAT 22 through one or more gateways 25001, 25002 and 
Mobile Networks 25009, 25010. At this point the device receives the content and follows the 
algorithms described above to present the content to the user. During content delivery queuing 
and other related delivery processing Push Manager 1012 generates messages with delivery 
status notifications on each status change and publishes them through the Push Interface 1014 to 
messaging Queues or Topics 25012 in Messaging System 25003, 25008. AppUcation Server 
25005, 25007 can subscribe to the queues and topics through Subscriptions 25004 in order to 
obtain delivery status notifications if they are required by the application algorithms. Currently 
the PES 27 generates the messages for the following delivery events: The content is placed in the 
queue; The content is replaced in the queue (older content was suppressed to ensure delivery of 
the most fresh content only); The content delivery failed (with attempt number and error code), 
and delivery attempts will continue until queue for the frame expires; The content is delivered to 
the target device; The content expired (queue for the frame may be reset upon expiration of 
application-configured timeout). 



Regarding claim 17 
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Referring to claim 17 Mil<liailov discloses all the limitations of claim 17 which is 
described above. Mikhailov also discloses wherein said processor is further for queuing 
said given message on said queue prior to pushing said given message, and wherein 

said pushing by said processor comprises, for each message on said queue, dequeuing 
said message from said queue and pushing said each message. (Col. 61 Fig. 61 FIG. 
34A is a block diagram illustrating the invented server-initiated content delivery process (see 
also FIG. 35A). The delivery request originates at the appUcation server 25005, 25007, in 
response to application algorithms, that can be defined by those skilled in art at application 
design time. The request then follows to Messaging Systems 25003, 25008 to the messaging 
queue or topic that the application and PES 27 negotiated for content delivery requests. In this 
architecture the Application Server 25005, 25007 is the publisher of the messages to the 
messaging topics or queues 25012 and the PES 27 is the subscriber for the messages through 
message subscription(s) 25004. When the message arrives to the PES 27 it is received by Push 
Interface 1014, which provides bridging and decoding functions between Messaging System 
25003, 25008 and PES 27 components. Once the message is processed the information follows 
to the Content Manager 1021, which fetches content delivery request data from the Application 
Servers 25005, 25007 or any other content provider using HTTP requests through Web Server 24 
or other applicable means. Upon it receiving the data PES 27, preprocesses and validates it, and 
saves the content to the Queue 46, which stores the content in Queue storage 1020. In the next 
step the Content Manager 1021 communicates to the router 1017, which reads information from 
Routing tables 47, to decide if the device is available and can process server-initiated content 
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delivery. Once the device is available, the content is sent to the PAT 22 through one or more 
gateways 25001, 25002 and Mobile Networks 25009, 25010. At this point the device receives 
the content and follows the algorithms described above to present the content to the user. During 
content delivery queuing and other related delivery processing Push Manager 1012 generates 
messages with delivery status notifications on each status change and publishes them through the 
Push Interface 1014 to messaging Queues or Topics 25012 in Messaging System 25003, 25008. 
Application Server 25005, 25007 can subscribe to the queues and topics through Subscriptions 
25004 in order to obtain delivery status notifications if they are required by the application 
algorithms. Currently the PES 27 generates the messages for the following delivery events: The 
content is placed in the queue; The content is replaced in the queue (older content was 
suppressed to ensure delivery of the most fi-esh content only); The content delivery failed (with 
attempt number and error code), and delivery attempts will continue until queue for the fi-ame 
expires; The content is delivered to the target device; The content expired (queue for the fi-ame 
may be reset upon expiration of application-configured timeout) . 

Regarding claim 18 

Referring to claim 18 Mikhailov discloses all the limitations of claim 18 which is 
described above. Mikhailov also discloses wherein said processor is further for, prior to 
said dequeuing and pushing, acquiring a lock for said destination on said application 
server, said lock preventing other of said destination. (Col.23 lines 61-67 and Col. 25 lines 
1-3 If field worker accepts the work order, the "YES" branch is followed to routine 2046, in 
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which the application updates the work order information, and locks it so that multiple field 
workers are not assigned to perform the same work. Then the apphcation enters idle state until 
the application receives work order completion notification from the field worker; it follows to 
routine 2047, in which the application updates work order information according to the response 
from the field worker, and follows to routine 2048. In routine 2048 the system may send status 
reports to the field worker. Routine 2048 is followed by the "END" step, which concludes 
routine 2020.) 



Regarding claim 19 

Referring to claim 19 Mikhailov discloses all the limitations of claim 19 which is 

described above. Mikhailov also discloses wherein messages on each of said at least 
one queue are queued on a first in first out basis and wherein said processor is for 
refraining from pushing a trailing message in said queue until said processor considers 
a message in said queue immediately preceding said trailing message has successfully 
reached said destination. (Col. 61 Fig. 61 FIG. 34A is a block diagram illustrating the 
invented server-initiated content delivery process (see also FIG. 3 5 A). The delivery request 
originates at the application server 25005, 25007, in response to application algorithms, that can 
be defined by those skilled in art at application design time. The request then follows to 
Messaging Systems 25003, 25008 to the messaging queue or topic that the application and PES 
27 negotiated for content delivery requests. In this architecture the Application Server 25005, 
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25007 is the publisher of the messages to the messaging topics or queues 25012 and the PES 27 
is the subscriber for the messages through message subscription(s) 25004. When the message 
arrives to the PES 27 it is received by Push Interface 1014, which provides bridging and 
decoding functions between Messaging System 25003, 25008 and PES 27 components. Once the 
message is processed the information follows to the Content Manager 1021, which fetches 
content delivery request data from the Application Servers 25005, 25007 or any other content 
provider using HTTP requests through Web Server 24 or other applicable means. Upon it 
receiving the data PES 27, preprocesses and validates it, and saves the content to the Queue 46, 
which stores the content in Queue storage 1020. In the next step the Content Manager 1021 
communicates to the router 1017, which reads information from Routing tables 47, to decide if 
the device is available and can process server-initiated content delivery. Once the device is 
available, the content is sent to the PAT 22 through one or more gateways 25001, 25002 and 
Mobile Networks 25009, 25010. At this point the device receives the content and follows the 
algorithms described above to present the content to the user. During content delivery queuing 
and other related delivery processing Push Manager 1012 generates messages with delivery 
status notifications on each status change and publishes them through the Push Interface 1014 to 
messaging Queues or Topics 25012 in Messaging System 25003, 25008. AppUcation Server 
25005, 25007 can subscribe to the queues and topics through Subscriptions 25004 in order to 
obtain delivery status notifications if they are required by the application algorithms. Currently 
the PES 27 generates the messages for the following delivery events: The content is placed in the 
queue; The content is replaced in the queue (older content was suppressed to ensure delivery of 
the most fresh content only); The content delivery failed (with attempt number and error code). 
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and delivery attempts will continue until queue for the frame expires; The content is delivered to 
the target device; The content expired (queue for the frame may be reset upon expiration of 
application-configured timeout) 

Regarding claim 20 

Referring to claim 20 Mikhailov discloses all the limitations of claim 20 which is 
described above. Mikhailov also discloses wherein said processor is further for, if a 
given message pushed from said given queue toward said destination does not 
successfully reach said destination, ceasing said dequeuing and pushing and re- 
queuing said given message on said given queue. (Col.62 Fig.35B lines 39-55 FIG. 35B 
is a logic flow diagram illustrating content loading routine 26004 of the server-initiated content 
delivery process 26000. This routine is typically implemented by the content manager 1021 in 
the PES 27. Routine 26004 starts with routine 26030, in which the content manager 1021 
receives request to download certain content for the server-initiated content delivery request. 
Routine 26030 follows to routine 26031 in which the content manager 1021 loads the content 
from the URL read from the content delivery request and follows to the step 25033, in which it 
checks whether loading was successfiil. If loading was not successful, the "NO" branch is 
followed to routine 26043, in which the PES 27 sends the delivery failed message to the 
application server, which initiated content delivery request, through Messaging System 25008, 
25003. If loading was successfiil, the "YES" branch is followed to the step 25035, in which the 
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server checks if the content is of supported type. Here supported type is the type, which can be 
transformed by the gateway 23 to the type understood by the PAT 22.) 

Regarding claim 21 

Referring to claim 21 Mil<liailov discloses a computer readable medium containing 
computer executable instructions for enabling use of an application server application 
by a wireless communication device, said computer executable instructions, when 
controlling a processor of a transaction server, causing said transaction server to: on 
receipt of a given message from said wireless communication device for said 
application on said application server, push said given message, each message queued 
on a queue for said application, toward a destination for said application of said 
application server. (Col. 61 FIG. 34B is a block diagram illustrating the invented application- 
specific device presence monitoring. The registration/deregistration request originates on the 
device as a result of routine 17000. It is submitted from the PAT 22 through Mobile Network(s) 
25009, 25010 to Gateway(s) 25001, 25002, which vnll deliver the request to the Presence 
Monitor 1019 in the PES 27. The Presence Monitor 1019 checks the records according to 
algorithm 23000, and may communicate with Routing Tables 1032 to obtain device status before 
the request arrived. If the device status is changed, it will issue device presence update message 
to the Push Manager 1012, which through the Push Interface 1014 will publish the message to 
some Messaging System 25008, 25003, to a specific Topic or Queue 25012 the Application 
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Server 25005, 25004 is subscribed to, through Subscription(s) 25004. Then Application Server 
25005, 25004 receives the device network presence update message and may execute the 
application-specific logic. It is understood that the described process is an optional extension, 
which may be ignored by the applications not sensitive to device network presence.) 

Conclusion 

Any inquiry concerning this communication or earlier communications from tlie 
examiner should be directed to Ashley d. Turner whose telephone number is 571-270- 
1603. The examiner can normally be reached on Monday thru Friday 7:30a.m. - 
5:00p.m.. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan Flynn can be reached at 571-272-1915. The fax phone number for 
the organization where this application or proceeding is assigned is 571-270-2603. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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